Control and use of chroma quantization parameter values

ABSTRACT

Innovations in control and use of chroma quantization parameter (“QP”) values that depend on luma QP values. More generally, the innovations relate to control and use of QP values for a secondary color component that depend on QP values for a primary color component. For example, during encoding, an encoder determines a QP index from a primary component QP and secondary component QP offset. The encoder maps the QP index to a secondary component QP, which has an extended range. The encoder outputs at least part of a bitstream including the encoded content. A corresponding decoder receives at least part of a bitstream including encoded content. During decoding, the decoder determines a QP index from a primary component QP and secondary component QP offset, then maps the QP index to a secondary component QP, which has an extended range.

CROSS REFERENCE TO RELATED APPLICATION

This application claims the benefit of U.S. Provisional PatentApplication No. 61/667,381, filed Jul. 2, 2012, the disclosure of whichis hereby incorporated by reference.

BACKGROUND

Engineers use compression (also called source coding or source encoding)to reduce the bit rate of digital video. Compression decreases the costof storing and transmitting video information by converting theinformation into a lower bit rate form. Decompression (also calleddecoding) reconstructs a version of the original information from thecompressed form. A “codec” is an encoder/decoder system.

Over the last two decades, various video codec standards have beenadopted, including the H.261, H.262 (MPEG-2 or ISO/IEC 13818-2), H2.63and H2.64 (AVC or ISO/IEC 14496-10) standards and the MPEG-1 (ISO/IEC11172-2), MPEG-4 Visual (ISO/IEC 14496-2) and SMPTE 421M standards. Morerecently, the HEVC standard is under development. A video codec standardtypically defines options for the syntax of an encoded video bitstream,detailing parameters in the bitstream when particular features are usedin encoding and decoding. In many cases, a video codec standard alsoprovides details about the decoding operations a decoder should performto achieve correct results in decoding. Aside from codec standards,various proprietary codec formats define other options for the syntax ofan encoded video bitstrearn and corresponding decoding operations.

One type of parameter in a bitstream is a quantization parameter (“QP”).During encoding, an encoder sets values of QP to adjust quality andbitrate. In general, for a lower value of QP, the quality of the encodedvideo is higher but more bits are consumed. On the other hand, for ahigher value of QP, the quality of the encoded video is lower and fewerbits are consumed. A decoder uses QP values when reconstructing videocontent from the encoded video.

A video source such as a camera, animation output, screen capturemodule, etc. typically provides video that is converted to a format suchas a YUV format, A YUV format includes a luma (or Y) component withsample values representing brightness values as well as multiple chromacomponents with sample values representing color difference values. Theprecise definitions of the color difference values (and conversionoperations to/from YUV color space to another color space such as RGB)depend on implementation. In general, a luma/chroma color space can beany color space with a luma (or luminance) component and one or morechroma (or chrominance) components, including YUV, Y′UV, YIQ, Y′IQ andYDbDr as well as variations such as YCbCr and YCoCg, where the Y termrepresents a luma component and the other terms represent chromacomponents.

For some codec standards and formats, an encoder can set differentvalues of QP for a luma component and chroma components. In this way,the encoder can control how quantization is performed for differentcolor components, and thereby regulate quality and bitrate betweencomponents. Prior approaches to controlling and using QP values forchroma components have various shortcomings, however, including a lackof fine-grained control in high QP situations, and failure to provide anappropriate level of responsiveness in other decoding operations.

SUMMARY

In summary, the detailed description presents innovations in control anduse of chroma quantization parameter (“QP”) values that depend on lumaQP values. More generally, the innovations relate to control and use ofQP values for a secondary color component (e.g., a chroma component)that depend on QP values for a primary color component (e.g., a lumacomponent).

For example, an image or video encoder encodes video or other contentwith multiple color components for which values of QP vary according toa relationship between a primary component and at least one secondarycomponent. The encoder determines a QP index from a primary component QPand a secondary component QP offset; which indicates a difference fromthe primary component QP. The encoder then maps the QP index to asecondary component QP. An upper limit of range of quantization stepsize (“QSS”) indicated by the secondary component QP substantiallymatches an upper limit of range of QSS indicated by the primarycomponent QP. Thus, secondary component QP has an extended rangecompared to certain prior approaches. The encoder outputs at least partof a bitstream including the encoded video or other content.

Or, a decoder receives at least part of a bitstrearn including encodedvideo or other content with multiple color components for which valuesof QP vary according to a. relationship between a primary component andat least one secondary component. The decoder decodes the encoded video.In particular, the decoder determines a QP index from a primarycomponent QP and a secondary component QP offset, then maps the QP indexto a secondary component QP. An upper limit of range of quantizationstep size (“QSS”) indicated by the secondary component QP substantiallymatches an upper limit of range of QSS indicated by the primarycomponent QP.

For example, the primary component is a luma component, and each of theat least one secondary component is a chroma component. The at least onesecondary component can include multiple chroma components, in whichcase values of QP can be different for different chroma components.

Typically, values of QP for the primary component are signaled, andvalues of QP for the at least one secondary component are derivedaccording to the relationship. The relationship can be specified atleast in part with a lookup table. Or, the relationship can be specifiedat least in part with logic that implements a piece-wise linearfunction.

In some implementations, according to the relationship, for values of QPthat indicate high QSS (i.e., coarse quantization) relative to athreshold, change in value of QP for the primary component causes achange of the same size in value of QP for the at least one secondarycomponent. Typically, a quantization step size (“QSS”) depends on QPvalue according to defined relation. Thus, for values of QP thatindicate high QSS, QSSs represented by values of QP change at a constantratio of (a) QSS represented by value of QP for the primary component to(b) QSS represented by value of QP for the at least one secondarycomponent.

In some implementations, according to the relationship, for values of QPthat indicate high QSS, a constant value of QP offset yields a QSSrepresented by value of QP for the primary component that is equal tothe QSS represented by the corresponding value of QP for the at leastone secondary component. In other words, for values of QP that indicatehigh QSS, for a given value of secondary component QP offset, the QSSrepresented by a value of QP for the primary component remains equal tothe QSS represented by the corresponding value of QP for the at leastone secondary component.

In some implementations, according to the relationship, derivation of anindex value used to find a chroma QP value is based at least in part ona slice-level chroma QP offset. A picture-level chroma QP offset can beused to specify a difference for chroma QP value that applies for apicture. A slice-level chroma QP offset can be used to specify adifference for chroma QP value that applies for a slice, which is partof a picture, in addition to a picture-level chroma QP offset. Theuse/non-use of the slice-level chroma QP offset (or presence/absence ofsuch slice-level chroma QP offset in the bitstream) can be indicated bya syntax element of a structure in the bitstream. For example, thesyntax element of the structure is a flag value in a picture parameterset.

As another example, a video encoder encodes video with multiple colorcomponents for which values of QP vary according to a relationshipbetween a primary component and at least one secondary component. Theencoding includes deblock filtering during which derivation of a controlparameter is based at least in part on a chroma QP offset. The chroma QPoffset can be specified with a picture-level chroma. QP offset orcombination of picture-level and slice-level chroma QP offsets. Theencoder outputs at least part of a bitstream or bitstream portionincluding the encoded video.

Or, a video decoder receives at least part of a bitstream or bitstreamportion including encoded video with multiple color components for whichvalues of QP vary according to a relationship between a primarycomponent and at least one secondary component. The decoder decodes theencoded video. The decoding includes deblock filtering during whichderivation of a control parameter is based at least in part on a chroma.QP offset. The chroma QP offset can be specified with a picture-levelchroma QP offset or combination of picture-level and slice-level chromaQP offsets.

The encoding or decoding can be implemented as part of a method, as partof a computing device adapted to perform the method or as part of atangible computer-readable media storing computer-executableinstructions for causing a computing device to perform the method.

The foregoing and other objects, features, and advantages of theinvention will become more apparent from the following detaileddescription, which proceeds with reference to the accompanying figures.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of an example computing system in which somedescribed embodiments can be implemented.

FIGS. 2 a and 2 b are diagrams of example network environments in whichsonic described embodiments can be implemented.

FIG. 3 is a diagram of an example encoder system in conjunction withwhich some described embodiments can be implemented.

FIG. 4 is a diagram of an example decoder system in conjunction withwhich some described embodiments can be implemented.

FIG. 5 is a diagram illustrating an example video encoder in conjunctionwith which some described embodiments can be implemented.

FIG. 6 is a diagram illustrating an example video decoder in conjunctionwith which some described embodiments can be implemented.

FIG. 7 is a flowchart illustrating a generalized technique fordetermining chroma QP during encoding.

FIG. 8 is a flowchart illustrating a generalized technique fordetermining chroma QP during decoding.

FIG. 9 a is a table illustrating a new flag slicelevel_chroma_qp_flag inpicture parameter set RBSP syntax, and FIG. 9 b is a table illustratingnew values slice_qp_delta_cb and slice_qp_delta_cr in slice headersyntax.

DETAILED DESCRIPTION

For compression of video content and other image content that uses amulti-component color space representation, an important aspect of thedesign is control of the granularity of the quantization for each of thecolor components. Such control is typically achieved by establishing ascaling relationship between the quantization step size(s) associatedwith one color component (often called the primary component) and othercolor component (often called a secondary component). Typically, theprimary component is a luma component, and the secondary component(s)are chroma component(s).

For example, in the ITU-T H.264 standard, the relationship between QPfor a luma component and chrom.a components is determined according to avalue of QP, a look-up table and an encoder-controlled offset, sometimestogether with a quantization scaling matrix for establishingfrequency-specific scaling factors. There are some disadvantages toexisting designs for this aspect of coding control for QP. For example,the maximum value of QP for chroma components in H.264 (indicatingcoarsest quantization for chroma) is limited to a value that issubstantially smaller than the maximum value of QP supported for theluma component (indicating coarsest quantization for luma). This cancause an excess quantity of bits to be used to encode the chromacomponents of the video content, when the coarseness of quantization islimited by the maximum value of QP for chroma, which results in fewerbits being used to encode the luma component of the video content andcan cause a reduction in overall quality.

The detailed description presents various approaches to controlling thegranularity of quantization of secondary components in relation to thatof the primary component. In many cases, these approaches alleviate theshortcomings of the prior approaches. In particular, the detaileddescription presents innovations for use of chroma QP values having anextended range.

For example, the described approaches include use of an extended sizefor the lookup table that may be used to establish the relationshipbetween the primary and secondary color components. As another example,the functional relationship in QP values established by such a lookuptable can alternatively be provided through the use of simplemathematical operations. Additional innovative aspects of control of QPvalues in video coding and decoding are also described. The describedtechniques may be applied to additional applications other than videocoding/decoding, such as still-image coding/decoding, medical scancontent coding/decoding, multispectral imagery content coding/decoding,etc. Although operations described herein are in places described asbeing performed by an encoder (e.g., video encoder) or decoder (e.g.,video decoder), in many cases the operations can alternatively beperformed by another type of media processing tool.

Some of the innovations described herein are illustrated with referenceto syntax elements and operations specific to the HEVC standard. Forexample, reference is made to the draft version JCTVC-I1003 of the HEVCstandard—“High efficiency video coding (“HEVC”) text specification draft7”, JCTVC-I1003_d5, 9^(th) meeting, Geneva, April 2012. The innovationsdescribed herein can also be implemented for other standards or formats.

Some of the innovations described herein are illustrated with referenceto syntax elements and operations for color components in a YCbCrformat. The innovations described herein can also be implemented forother lumalchroma formats such as Y′UV, YIQ, X″ IQ and YDbDr as well asvariations such as YCoCg. Examples for Cb and Cr components should beunderstood as applying equally when chroma components are U and V, I andQ, Db and Dr, Co and Cg, or chroma components in another format.

More generally, various alternatives to the examples described hereinare possible. For example, some of the methods described herein can bealtered by changing the ordering of the method acts described, bysplitting, repeating, or omitting certain method acts, etc. The variousaspects of the disclosed technology can be used in combination orseparately. Different embodiments use one or more of the describedinnovations. Some of the innovations described herein address one ormore of the problems noted in the background. Typically, a giventechnique/tool does not solve all such problems.

I. Example Computing Systems

FIG. 1 illustrates a generalized example of a suitable computing system(100) in which several of the described innovations may be implemented.The computing system (100) is not intended to suggest any limitation asto scope of use or functionality, as the innovations may be implementedin diverse general-purpose or special-purpose computing systems.

With reference to FIG. 1 , the computing system (100) includes one ormore processing units (110, 115) and memory (120, 125). In FIG. 1 , thismost basic configuration (130) is included within a dashed line. Theprocessing units (110, 115) execute computer-executable instructions. Aprocessing unit can be a general-purpose central processing unit (CPU),processor in an application-specific integrated circuit (ASIC) or anyother type of processor. In a multi-processing system, multipleprocessing units execute computer-executable instructions to increaseprocessing power. For example, FIG. 1 shows a central processing unit(110) as well as a graphics processing unit or co-processing unit (115).The tangible memory (120, 125) may be volatile memory (e.g., registers,cache, RAM), non-volatile memory (e.g., ROM, EEPROM, flash memory,etc.), or some combination of the two, accessible by the processingunit(s). The memory (120, 125) stores software (180) implementing one ormore innovations for encoding or decoding of video or other contentusing an extended range of chroma QP values, in the form ofcomputer-executable instructions suitable for execution by theprocessing unit(s).

A computing system may have additional features, For example, thecomputing system (100) includes storage (140), one or more input devices(150), one or more output devices (160), and one or more communicationconnections (170). An interconnection mechanism (not shown) such as abus, controller, or network interconnects the components of thecomputing system (100). Typically, operating system software (not shown)provides an operating environment for other software executing in thecomputing system (100), and coordinates activities of the components ofthe computing system (100).

The tangible storage (140) may be removable or non-removable, andincludes magnetic disks, magnetic tapes or cassettes, CD-ROMs, DVDs, orany other medium which can be used to store information and which can beaccessed within the computing system (100). The storage (140) storesinstructions for the software (180) implementing one or more innovationsfor encoding or decoding of video or other content using extended-rangechroma QP values.

The input device(s) (150) may be a touch input device such as akeyboard, mouse, pen, or trackball, a voice input device, a scanningdevice, or another device that provides input to the computing system(100). For video encoding, the input device(s) (150) may be a camera,video card, TV tuner card, or similar device that accepts video input inanalog or digital form, or a CD-ROM or CD-RW that reads video samplesinto the computing system (100). The output device(s) (160) may be adisplay, printer, speaker, CD-writer, or another device that providesoutput from the computing system (100).

The communication connection(s) (170) enable communication over acommunication medium to another computing entity. The communicationmedium conveys information such as computer-executable instructions,audio or video input or output, or other data in a modulated datasignal. A modulated data signal is a signal that has one or more of itscharacteristics set or changed in such a manner as to encode informationin the signal. By way of example, and not limitation, communicationmedia can use an electrical, optical, RF, or other carrier.

The innovations can be described in the general context ofcomputer-readable media. Computer-readable media are any availabletangible media that can be accessed within a computing environment. Byway of example, and not limitation, with the computing system (100),computer-readable media include memory (120, 125), storage (140), andcombinations of any of the above.

The innovations can be described in the general context ofcomputer-executable instructions, such as those included in programmodules, being executed in a computing system on a target real orvirtual processor. Generally, program modules include routines,programs, libraries, objects, classes, components, data structures, etc.that perform particular tasks or implement particular abstract datatypes. The functionality of the program modules may be combined or splitbetween program modules as desired in various embodiments.Computer-executable instructions for program modules may be executedwithin a local or distributed computing system.

The terms “system” and “device” are used interchangeably herein. Unlessthe context clearly indicates otherwise, neither term implies anylimitation on a type of computing system or computing device. Ingeneral, a computing system or computing device can be local ordistributed, and can include any combination of special-purpose hardwareand/or general-purpose hardware with software implementing thefunctionality described herein.

The disclosed methods can also be implemented using specializedcomputing hardware configured to perform any of the disclosed methods.For example, the disclosed methods can be implemented by an integratedcircuit (e.g., an application specific integrated. circuit (“ASIC”)(such as an ASIC digital signal process unit (“DSP”), a graphicsprocessing unit (“GPU”), or a programmable logic device (“PLD”), such asa field programmable gate array (“FPGA”)) specially designed orconfigured to implement any of the disclosed methods.

For the sake of presentation, the detailed description uses terms like“determine” and “use” to describe computer operations in a computingsystem. These terms are high-level abstractions for operations performedby a computer, and should not be confused with acts performed by a humanbeing. The actual computer operations corresponding to these terms varydepending on implementation.

II. Example Network Environments

FIGS. 2 a and 2 b show example network environments (201, 202) thatinclude video encoders (220) and video decoders (270). The encoders(220) and decoders (270) are connected over a network (250) using anappropriate communication protocol. The network (250) can include theInternet or another computer network.

In the network environment 201) shown in FIG. 2 a , each real-timecommunication (“RTC”) tool (210) includes both an encoder (220) and adecoder (270) for bidirectional communication. A given encoder (220) canproduce output compliant with the SMPTE 421M standard, ISO-IEC 14496-10standard (also known as H.264 or AVC), HEVC standard, another standard,or a proprietary format, with a corresponding decoder (270) acceptingencoded data from the encoder (220). The bidirectional communication canbe part of a video conference, video telephone call, or other two-partycommunication scenario. Although the network environment (201) in FIG. 2a includes two real-time communication tools (210), the networkenvironment (201) can instead include three or more real-timecommunication tools (210) that participate in multi-party communication.

A real-time communication tool (210) manages encoding by an encoder(220). FIG. 3 shows an example encoder system (300) that can be includedin the real-time communication tool (210). Alternatively, the real-timecommunication tool (210) uses another encoder system. A real-timecommunication. tool (210) also manages decoding by a decoder (270). FIG.4 shows an example decoder system (400), which can be included in thereal-time communication tool (210). Alternatively, the real-timecommunication tool (210) uses another decoder system,

In the network environment (202) shown in FIG. 2 b , an encoding tool(212) includes an encoder (220) that encodes video for delivery tomultiple playback tools (214), which include decoders (270). Theunidirectional communication can be provided for a video surveillancesystem, web camera monitoring system, remote desktop conferencingpresentation or other scenario in which video is encoded and sent fromone location to one or more other locations. Although the networkenvironment (202) in FIG. 2 b includes two playback tools (214), thenetwork environment (202) can include more or fewer playback tools(214). In general, a playback tool (214) communicates with the encodingtool (212) to determine a stream of video for the playback tool (214) toreceive. The playback tool (214) receives the stream, buffers thereceived encoded data for an appropriate period, and begins decoding andplayback.

FIG. 3 shows an example encoder system (300) that can. be included inthe encoding tool (212). Alternatively, the encoding tool (212) usesanother encoder system. The encoding tool (212) can also includeserver-side controller logic for managing connections with one or moreplayback tools (214). FIG. 4 shows an example decoder system (400),which can be included in the playback tool (214). Alternatively, theplayback tool (214) uses another decoder system. A playback tool (214)can also include client-side controller logic for managing connectionswith the encoding tool (212).

III. Example Encoder Systems

FIG. 3 is a block diagram of an example encoder system (300) inconjunction with which some described embodiments may be implemented.The encoder system (300) can be a general-purpose encoding tool capableof operating in any of multiple encoding modes such as a low-latencyencoding mode for real-time communication, transcoding mode, and regularencoding mode for media playback from a file or stream, or it can be aspecial-purpose encoding tool adapted for one such encoding mode, Theencoder system (300) can be implemented as an operating system module,as part of an application library or as a standalone application.Overall, the encoder system (300) receives a sequence of source videoframes (311) from a video source (310) and produces encoded data asoutput to a channel (390). The encoded data output to the channel caninclude syntax elements that indicate QP values for chroma, such aspicture-level chroma QP offsets and/or slice-level chroma QP offsets.

The video source (310) can be a camera, tuner card, storage media, orother digital video source. The video source (310) produces a sequenceof video frames at a frame rate of, for example, 30 frames per second.As used herein, the term “frame” generally refers to source, coded orreconstructed image data. For progressive video, a frame is aprogressive video frame. For interlaced video, in example embodiments,an interlaced video frame is de-interlaced prior to encoding.Alternatively, two complementary interlaced video fields are encoded asan interlaced video frame or separate fields. Aside from indicating aprogressive video frame, the term “frame” can indicate a singlenon-paired video field, a complementary pair of video fields, a videoobject plane that represents a video object at a given time, or a regionof interest in a larger image. The video object plane or region can bepart of a larger image that includes multiple objects or regions of ascene.

An arriving source frame (311) is stored in a source frame temporarymemory storage area (320) that includes multiple frame buffer storageareas (321, 322, . . . , 32 n). A frame buffer (321, 322, etc.) holdsone source frame in the source frame storage area (320). After one ormore of the source frames (311) have been stored in frame buffers (321,322, etc.), a frame selector (330) periodically selects an individualsource frame from the source frame storage area (320). The order inwhich frames are selected by the frame selector (330) for input to theencoder (340) may differ from the order in which the frames are producedby the video source (310), e.g., a frame may be ahead in order, tofacilitate temporally backward prediction. Before the encoder (340), theencoder system (300) can include a pre-processor (not shown) thatperforms pre-processing (e.g., filtering) of the selected frame (331)before encoding, The pre-processing can also include color spaceconversion into primary and secondary components for encoding.

The encoder (340) encodes the selected frame (331) to produce a codedframe (341) and also produces memory management control operation(“MMCO”) signals (342) or reference picture set (“RPS”) information, Ifthe current frame is not the first frame that has been encoded, whenperforming its encoding process, the encoder (340) may use one or morepreviously encoded/decoded frames (369) that have been stored in adecoded frame temporary memory storage area (360). Such stored decodedframes (369) are used as reference frames for inter-frame prediction ofthe content of the current source frame (331). Generally, the encoder(340) includes multiple encoding modules that perform encoding taskssuch as motion estimation and compensation, frequency transforms,quantization and entropy coding. The exact operations performed by theencoder (340) can vary depending on compression format. The format ofthe output encoded data can be a Windows Media Video format, VC-1format, MPEG-x format (e.g., MPEG-1, MPEG-2, or MPEG-4), H.26x format(e.g., H.261, H.262, H.263, H.264), HEVC format or other format.

For example, within the encoder (340), an inter-coded, predicted frameis represented in terms of prediction from reference frames. A motionestimator estimates motion of blocks or other sets of samples of asource frame (341) with respect to one or more reference frames (369).When multiple reference frames are used, the multiple reference framescan be from different temporal directions or the same temporaldirection. The motion estimator outputs motion information such asmotion vector information, which is entropy coded. A motion compensatorapplies motion vectors to reference frames to determinemotion-compensated prediction values. The encoder determines thedifferences (if any) between a block's motion-compensated predictionvalues and corresponding original values. These prediction residualvalues are further encoded using a frequency transform, quantization andentropy encoding. The quantization can use values of chroma QP. Forexample, the encoder (340) sets values for luma QP and chroma QP for apicture, slice and/or other portion of video, and quantizes transformcoefficients accordingly. Similarly, for intra prediction, the encoder(340) can determine intra-prediction values for a block, determineprediction residual values, and encode the prediction residual values(with a frequency transform, quantization and entropy encoding). Inparticular, the entropy coder of the encoder (340) compresses quantizedtransform coefficient values as well as certain side information. (e.g.,motion vector information, QP values, mode decisions, parameterchoices). Typical entropy coding techniques include Exp-Golomb coding,arithmetic coding, differential coding, Huffman coding, run lengthcoding, variable-length-to-variable-length (“V2V”) coding,variable-length-to-fixed-length (“V2F”) coding, LZ coding, dictionarycoding, probability interval partitioning entropy coding (“PIPE”), andcombinations of the above. The entropy coder can use different codingtechniques for different kinds of information, and can choose from amongmultiple code tables within a particular coding technique.

The coded frames (341) and MMCO/RPS information (342) are processed by adecoding process emulator (350). The decoding process emulator (350)implements some of the functionality of a decoder, for example, decodingtasks to reconstruct reference frames that are used by the encoder (340)in motion estimation and compensation. The decoding process emulator(350) uses the MMCO/RPS information (342) to determine whether a givencoded frame (341) needs to be reconstructed and stored for use as areference frame in inter-frame prediction of subsequent frames to beencoded. If the MMCO/RPS information (342) indicates that a coded frame(341) needs to be stored, the decoding process emulator (350) models thedecoding process that would be conducted by a decoder that receives thecoded frame (341) and produces a corresponding decoded frame (351). Indoing so, when the encoder (340) has used decoded frame(s) (369) thathave been. stored in the decoded frame storage area (360), the decodingprocess emulator (350) also uses the decoded frame(s) (369) from thestorage area (360) as part of the decoding process.

The decoded frame temporary memory storage area (360) includes multipleframe buffer storage areas (361, 362, . . . , 36 n). The decodingprocess emulator (350) uses the MMCO/RPS information. (342) to managethe contents of the storage area (360) in order to identify any framebuffers (361, 362, etc.) with frames that are no longer needed by theencoder (340) for use as reference frames. After modeling the decodingprocess, the decoding process emulator (350) stores a newly decodedframe (351) in a frame buffer (361, 362, etc.) that has been identifiedin this manner.

The coded frames (341) and MMCO/RPS information (342) are also bufferedin a temporary coded data area (370). The coded data that is aggregatedin the coded data area (370) can contain, as part of the syntax of anelementary coded video bitstream, syntax elements that indicate QPvalues set for chroma, such as picture-level chroma QP offsets and/orslice-level chroma QP offsets. The coded data that is aggregated in thecoded data area (370) can also include media metadata relating to thecoded video data (e.g., as one or more parameters in one or moresupplemental enhancement information (“SEI”) messages or video usabilityinformation (“VUI”) messages).

The aggregated data (371) from the temporary coded data area (370) areprocessed by a channel encoder (380). The channel encoder (380) canpacketize the aggregated data for transmission as a media stream (e,g.,according to a media container format such as ISO/IEC 14496-12), inwhich case the channel encoder (380) can add syntax elements as part ofthe syntax of the media transmission stream. Or, the channel encoder(380) can organize the aggregated data for storage as a file (e.g.,according to a media container format such as ISO/IEC 14496-12), inwhich case the channel encoder (380) can add syntax elements as part ofthe syntax of the media storage file. Or, more generally, the channelencoder (380) can implement one or more media system multiplexingprotocols or transport protocols, in which case the channel encoder(380) can add syntax elements as part of the syntax of the protocol(s).The channel encoder (380) provides output to a channel (390), whichrepresents storage, a communications connection, or another channel forthe output.

IV. Example Decoder Systems

FIG. 4 is a block diagram of an example decoder system (400) inconjunction with which some described embodiments may be implemented.The decoder system (400) can be a general-purpose decoding tool capableof operating in any of multiple decoding modes such as a low-latencydecoding mode for real-time communication and regular decoding mode formedia playback from a file or stream, or it can be a special-purposedecoding tool adapted for one such decoding mode. The decoder system(400) can be implemented as an operating system module, as part of anapplication library or as a standalone application. Overall, the decodersystem (400) receives coded data from a channel (410) and producesreconstructed frames as output for an output destination (490). Thecoded data can include syntax elements that indicate QP values set forchroma, such as picture-level chroma QP offsets and/or slice-levelchroma QP offsets.

The decoder system (400) includes a channel (410), which can representstorage, a communications connection, or another channel for coded dataas input. The channel (410) produces coded data that has been channelcoded. A channel decoder (420) can process the coded data. For example,the channel decoder (420) de-packetizes data that has been aggregatedfor transmission as a media stream (e.g., according to a media containerformat such as ISO/IEC 14496-12), in which case the channel decoder(420) can parse syntax elements added as part of the syntax of the mediatransmission stream. Or, the channel decoder (420) separates coded videodata that has been aggregated for storage as a file (e.g., according toa media container format such as ISO/IEC 14496-12), in which case thechannel decoder (420) can parse syntax elements added as part of thesyntax of the media storage file. Or, more generally, the channeldecoder (420) can implement one or more media system demultiplexingprotocols or transport protocols, in which case the channel decoder(420) can parse syntax elements added as part of the syntax of theprotocol(s).

The coded data (421) that is output from the channel decoder (420) isstored in a temporary coded data area (430) until a sufficient quantityof such data has been received. The coded data (421) includes codedframes (431) and MMCO/RPS infbrniation (432). The coded data (421) inthe coded data area (430) can contain, as part of the syntax of anelementary coded video bitstream, syntax elements that indicate QPvalues set for chroma, such as picture-level chroma QP offsets and/orslice-level chroma QP offsets. The coded data (421) in the coded dataarea (430) can also include media metadata relating to the encoded videodata (e.g., as one or more parameters in one or more SEI messages or VUImessages). In general, the coded data area (430) temporarily storescoded data (421) until such coded data (421) is used by the decoder(450). At that point, coded data for a coded frame (431) and MMCO/RPSinformation (432) are transferred from the coded data area (430) to thedecoder (450). As decoding continues, new coded data is added to thecoded data area (430) and the oldest coded data remaining in the codeddata area (430) is transferred to the decoder (450).

The decoder (450) periodically decodes a coded frame (431) to produce acorresponding decoded frame (451). As appropriate, when performing itsdecoding process, the decoder (450) may use one or more previouslydecoded frames (469) as reference frames for inter-frame prediction. Thedecoder (450) reads such previously decoded frames (469) from a decodedframe temporary memory storage area (460). Generally, the decoder (450)includes multiple decoding modules that perform decoding tasks such asentropy decoding, inverse quantization (which can use values of chromaQP), inverse frequency transforms and motion compensation. The exactoperations performed by the decoder (450) can vary depending oncompression format.

For example, the decoder (450) receives encoded data for a compressedframe or sequence of frames and produces output including decoded frame(451). In the decoder (450), a buffer receives encoded data for acompressed frame and makes the received encoded data available to anentropy decoder. The entropy decoder entropy decodes entropy-codedquantized data as well as entropy-coded side information, typicallyapplying the inverse of entropy encoding performed in the encoder. Amotion compensator applies motion information to one or more referenceframes to form motion-compensated predictions of sub-blocks and/orblocks (generally, blocks) of the frame being reconstructed. An intraprediction module can spatially predict sample values of a current blockfrom neighboring, previously reconstructed sample values. The decoder(450) also reconstructs prediction residuals. An inverse quantizerinverse quantizes entropy-decoded data, potentially using values ofchroma QP. For example, the decoder (450) sets values for luma QP andchroma QP for a picture, slice and/or other portion of video based onsyntax elements in the bitstream, and inverse quantizes transformcoefficients accordingly. An inverse frequency transformer converts thequantized, frequency domain data into spatial domain information. For apredicted frame, the decoder (450) combines reconstructed predictionresiduals with motion-compensated predictions to form a reconstructedframe. The decoder (450) can similarly combine prediction residuals withspatial predictions from intra prediction. A motion compensation loop inthe video decoder (450) includes an adaptive de-blocking filter tosmooth discontinuities across block boundary rows and/or columns in thedecoded frame (451).

The decoded frame temporary memory storage area (460) includes multipleframe buffer storage areas (461, 462, . . . , 46 n), The decoded framestorage area (460) is an example of a DPB. The decoder (450) uses theMMCO/RPS information (432) to identify a frame buffer (461, 462, etc.)in which it can store a decoded frame (451). The decoder (450) storesthe decoded frame (451) in that frame buffer.

An output sequencer (480) uses the MMCO/RPS information (432) toidentify when the next frame to be produced in output order is availablein the decoded frame storage area (460). When the next frame (481) to beproduced in output order is available in the decoded frame storage area(460), it is read by the output sequencer (480) and output to the outputdestination (490) (e.g., display). In general, the order in which framesare output from the decoded frame storage area (460) by the outputsequencer (480) may differ from the order in which the frames aredecoded by the decoder (450).

V. Example Video Encoders

FIG. 5 is a block diagram of a generalized video encoder (500) inconjunction with which some described embodiments may be implemented.The encoder (500) receives a sequence of video frames including acurrent frame (505) and produces encoded data (595) as output.

The encoder (500) is block-based and uses a block format that depends onimplementation. Blocks may be further sub-divided at different stages,e.g., at the frequency transform and entropy encoding stages. Forexample, a frame can be divided into 64×64 blocks, 32×32 blocks or 16×16blocks, which can in turn be divided into smaller blocks and sub-blocksof pixel values for coding and decoding.

The encoder system (500) compresses predicted frames and intra-codedframes. For the sake of presentation, FIG. 5 shows an “intra path”through the encoder (500) for intra-frame coding and an “inter path” forinter-frame coding. Many of the components of the encoder (500) are usedfor both intra-frame coding and inter-frame coding. The exact operationsperformed by those components can vary depending on the type ofinformation being compressed.

If the current frame (505) is a predicted frame, a motion estimator(510) estimates motion of blocks, sub-blocks or other sets of pixelvalues of the current frame (505) with respect to one or more referenceframes. The frame store (520) buffers one or more reconstructed previousframes (525) for use as reference frames. When multiple reference framesare used, the multiple reference frames can be from different temporaldirections or the same temporal direction. The motion estimator (510)outputs as side information motion information (515) such asdifferential motion vector information.

The motion compensator (530) applies reconstructed motion vectors to thereconstructed reference frame(s) (525) when forming a motion-compensatedcurrent frame (535). The difference (if any) between a sub-block, block,etc. of the motion-compensated current frame (535) and correspondingpart of the original current frame (505) is the prediction residual(545) for the sub-block, block, etc. During later reconstruction of thecurrent frame, reconstructed prediction residuals are added to themotion-compensated current frame (535) to obtain a reconstructed framethat is closer to the original current frame (505). In lossycompression, however, some information is still lost from the originalcurrent frame (505). The intra path can include an intra predictionmodule (not shown) that spatially predicts pixel values of a currentblock or sub-block from neighboring, previously reconstructed pixelvalues.

A frequency transformer (560) converts spatial domain video informationinto frequency domain (i.e., spectral, transform) data. For block-basedvideo frames, the frequency transformer (560) applies a discrete cosinetransform, an integer approximation thereof, or another type of forwardblock transform to blocks or sub-blocks of pixel value data orprediction residual data, producing blocks/sub-blocks of frequencytransform coefficients. A quantizer (570) then quantizes the transformcoefficients. For example, the quantizer (570) applies non-uniform,scalar quantization to the frequency domain data with a step size thatvaries on a frame-by-frame basis, slice-by-slice basis, block-by-blockbasis or other basis. The quantizer (570) can use QP values for lamacomponents and chroma components that include chroma QP values, asdescribed in Section VII. For example, the encoder (500) sets values forluma QP and chroma QP for a picture, slice and/or other portion of videosuch as a coding unit, and quantizes transform coefficients accordingly.

When a reconstructed version of the current frame is needed forsubsequent motion estimation/compensation, an inverse quantizer (576)performs inverse quantization on the quantized frequency coefficientdata. The inverse quantizer (576) can also use chroma QP values. Aninverse frequency transformer (566) performs an inverse frequencytransform, producing blocks/sub-blocks of reconstructed predictionresiduals or pixel values. For a predicted frame, the encoder (500)combines reconstructed prediction residuals (545) withmotion-compensated predictions (535) to form the reconstructed frame(505). (Although not shown in FIG. 5 , in the intra path, the encoder(500) can combine prediction residuals with spatial predictions fromintra prediction.) The frame store (520) buffers the reconstructedcurrent frame for use in subsequent motion-compensated prediction.

Quantization and other lossy processing can result in visible lines atboundaries between blocks or sub-blocks of a frame. Such “blockingartifacts” might occur, for example, if adjacent blocks in a smoothlychanging region of a picture (such as a sky area) are quantized todifferent average levels. To reduce blocking artifacts, an encoder anddecoder can use “deblock” filtering to smooth boundary discontinuitiesbetween blocks and/or sub-blocks in reference frames. Such filtering is“in-loop” in that it occurs inside a motion-compensation loop—theencoder and decoder perform it on reference frames used later inencoding/decoding. In-loop deblock filtering is usually enabled duringencoding, in which case a decoder also performs in-loop deblockfiltering for correct decoding. The details of deblock filtering varydepending on the codec standard or format, and can be quite complex.Often, the rules of applying deblock filtering can vary depending onfactors such as content/smoothness, coding mode (e.g., intra or inter),motion vectors for blocks/sub-blocks on different sides of a boundary,block/sub-block size, coded/not coded status (e.g., whether transformcoefficient information is signaled in the bitstream).

In FIG. 5 , a motion compensation loop in the encoder (500) includes anadaptive in-loop deblock filter (510) before or after the frame store(520). The decoder (500) applies in-loop filtering to reconstructedframes to adaptively smooth discontinuities across boundaries in theframes. Section VII describes examples in which deblock filteringchanges depending on value of chroma QP offset.

The entropy coder (580) compresses the output of the quantizer (570) aswell as motion information (515) and certain side information (e.g., QPvalues). The entropy coder (580) provides encoded data (595) to thebuffer (590), which multiplexes the encoded data into an outputbitstream. The encoded data can include syntax elements that indicate QPvalues set for chroma, such as picture-level chroma QP offsets and/orslice-level chroma QP offsets. Section VII describes examples of suchsyntax elements.

A controller (not shown) receives inputs from various modules of theencoder. The controller evaluates intermediate results during encoding,for example, setting QP values and performing rate-distortion analysis.The controller works with other modules to set and change codingparameters during encoding. In particular, the controller can vary QPvalues and other control parameters to control quantization of lumacomponents and chroma components during encoding.

In some implementations, the controller can set a picture-level luma QPvalue, slice-level luma QP value or coding-unit-level luma QP valueduring encoding so as to control quantization at the picture level,slice level or coding unit level within a slice. For a given slice, theluma QP value can be set to the picture-level luma QP or a slice-levelluma QP, which will be represented in the bitstream with thepicture-level luma QP plus a slice-level luma QP offset. Or, thecontroller can set a luma QP value for a given coding unit within theslice. In this case, a coding-unit-level luma QP offset is signaled inthe bitstream, along with a slice-level luma QP offset and thepicture-level luma QP value, to indicate the coding-unit-level luma QPvalue. Thus, different slices within a picture can have different lumaQP values specified, and different coding units within a slice can havedifferent luma QP values specified. The controller can also set apicture-level chroma QP value or slice-level chroma QP value, asindicated in the bitstream with one or more chroma QP offsets. A chromaQP offset does not directly specify the chroma QP value, but rather isused in a derivation process (as described in section VII) to determinethe chroma QP value. The controller can also specify a quantizationscaling matrix to establish frequency-specific scaling factors forcoefficients of a luma component and/or chroma. component.

A QP value controls the coarseness of the quantization of the luma andchroma transform coefficients. For example, a QP value may control ascaling factor also known as a quantization step size (“QSS”) accordingto a defined relationship. For example, the QP value is signaled in thebitstream as QP minus 26, and the QSS is S*2^((QP/6)) or approximatelyS*2^((QP/6)), where S is a scaling factor such as a fixed-valueconstant, a transform-specific scaling factor or a frequency-specificscaling factor. In some implementations, an integer-based formulaindicates a QSS that approximates S*2^((QP/6)). In this relationship, ahigh value of QP signifies a high (i.e., coarse) QSS, and a low value ofQP indicates a low (i.e., fine) QSS. Alternatively, QP can be inverselyrelated to QSS. For example, a QP value is signaled in the bitstream as25 minus QP, and the QSS is S*2^(((51−QP)/6)) or approximatelyS*2^(((51−QP)/6)). In this example, the same QSS values can effectivelybe signaled, but a high value of QP signifies a low QSS, and a low valueof QP signifies a high QSS. More generally, the innovations describedherein can be applied for various relationships between QP and QSS,including the relationships described above as well as relationships inwhich the QP is a parameter such as the parameter called QUANT in theH.263 standard, and relationships in which the QP is a parameter such asthe parameter called quantiser_scale in the H.262 standard.

In general, the controller can set luma QP and chroma QP for a picture,slice or other portion of video, and then evaluate results of encodingof the content (e.g., quantizing transform coefficients and/or entropycoding the quantized transform coefficients) in terms of quality and/orbitrate. If the results are satisfactory, the controller can select theluma QP and chroma QP that were set. Otherwise, the controller canadjust the luma QP and/or chroma QP. For example, if the quality ofencoded chroma content is too high relative to the quality of encodedluma content, the controller can adjust QP to increase chroma QSS and/ordecrease luma QSS to balance quality between luma and chroma componentswhile also considering overall targets for rate and/or quality. Or, ifthe quality of encoded chroma content is too low relative to the qualityof encoded luma content, the controller can adjust QP to decrease chromaQSS and/or increase luma QSS to balance quality between luma and chromacomponents while also considering overall targets for rate and/orquality. The setting and adjustment of luma QP and chroma QP can berepeated on a picture-by-picture basis, slice-by-slice basis or someother basis.

Depending on implementation and the type of compression desired, modulesof the encoder can be added, omitted, split into multiple modules,combined with other modules, and/or replaced with like modules. Inalternative embodiments, encoders with different modules and/or otherconfigurations of modules perform one or more of the describedtechniques. Specific embodiments of encoders typically use a variationor supplemented version of the encoder (500). The relationships shownbetween modules within the encoder (500) indicate general flows ofinformation in the encoder; other relationships are not shown for thesake of simplicity.

VI. Example Video Decoders

FIG. 6 is a block diagram of a generalized decoder (600) in conjunctionwith which several described embodiments may be implemented. The decoder(600) receives encoded data (695) for a compressed frame or sequence offrames and produces output including a reconstructed frame (605). Forthe sake of presentation, FIG. 6 shows an “intra path” through thedecoder (600) for intra-frame decoding and an “inter path” forinter-frame decoding. Many of the components of the decoder (600) areused for both intra-frame decoding and inter-frame decoding. The exactoperations performed by those components can vary depending on the typeof information being decompressed.

A buffer (690) receives encoded data (695) for a compressed frame andmakes the received encoded data available to the parser/entropy decoder(680). The encoded data can include syntax elements that indicate QPvalues set for chroma, such as picture-level chroma QP offsets and/orslice-level chroma QP offsets. Section VII describes examples of suchsyntax elements. The parser/entropy decoder (680) entropy decodesentropy-coded quantized data as well as entropy-coded side information,typically applying the inverse of entropy encoding performed in theencoder.

A motion compensator (630) applies motion information (615) to one ormore reference frames (625) to form motion-compensated predictions (635)of sub-blocks and/or blocks of the frame (605) being reconstructed. Theframe store (620) stores one or more previously reconstructed frames foruse as reference frames.

The intra path can include an intra prediction module (not shown) thatspatially predicts pixel values of a current block or sub-block. fromneighboring, previously reconstructed pixel values. in the inter path,the decoder (600) reconstructs prediction residuals. An inversequantizer (670) inverse quantizes entropy-decoded data, potentiallyusing values of chroma QP. For example, the decoder (600) sets valuesfor luma QP and chroma QP for a picture, slice and/or other portion ofvideo such as a coding unit, based on syntax elements in the bitstream,and the inverse quantizer (670) inverse quantizes transform coefficientsaccordingly.

In some implementations, the decoder can set a picture-level luma QPvalue, slice-level luma QP value or coding-unit-level luma QP valueduring decoding, as indicated by syntax elements in the bitstream,including a picture-level luma QP value, a slice-level luma QP offset(if present) and coding-unit-level luma QP offset (if present).Different slices within a picture can have different luma QP valuesspecified, and different coding units within a slice can have differentluma QP values specified. The decoder also sets a picture-level chromaQP value or slice-level chroma QP value, as indicated in the bitstreamwith one or more chroma QP offsets. The decoder can also use aquantization scaling matrix to establish frequency-specific scalingfactors for coefficients of a luma component and/or chroma component. AQP value represents a quantization step size (“QSS”) according to adefined relationship, as described above.

An inverse frequency transformer (660) converts the reconstructedfrequency domain data into spatial domain information. For example, theinverse frequency transformer (660) applies an inverse block transformto frequency transform coefficients, producing pixel value data orprediction residual data. The inverse frequency transform can be aninverse discrete cosine transform, an integer approximation thereof, oranother type of inverse frequency transform.

For a predicted frame, the decoder (600) combines reconstructedprediction residuals (645) with motion-compensated predictions (635) toform the reconstructed frame (605). (Although not shown in FIG. 6 , inthe intra path, the decoder (600) can combine prediction residuals withspatial predictions from intra prediction.) A motion compensation loopin the decoder (600) includes an adaptive in-loop deblock filter (610)before or after the frame store (620). The decoder (600) applies in-loopfiltering to reconstructed frames to adaptively smooth discontinuitiesacross boundaries in the frames. The details of deblock filtering duringdecoding (e.g., rules that depend on factors such as content/smoothness,coding mode, motion vectors for blocks/sub-blocks on different sides ofa boundary, block/sub-block size, coded/not coded status, etc.)typically mirror the details of deblock filtering during encoding

In FIG. 6 , the decoder (600) also includes a post-processing deblockfilter (608). The post-processing deblock filter (608) optionallysmoothes discontinuities in reconstructed frames. Other filtering (suchas de-ring filtering) can also be applied as part of the post-processingfiltering.

Depending on implementation and the type of decompression desired,modules of the decoder can be added, omitted, split into multiplemodules, combined with other modules, and/or replaced with like modules.In alternative embodiments, decoders with different modules and/or otherconfigurations of modules perform one or more of the describedtechniques. Specific embodiments of decoders typically use a variationor supplemented version of the decoder (600). The relationships shownbetween modules within the decoder (600) indicate general flows ofinformation in the decoder; other relationships are not shown for thesake of simplicity.

VII. Control and Use of Extended-Range Chroma QP Values

This section presents various innovations for controlling and usingchroma QP values.

In the HEVC design in JCTVC-I1003, the QP for chroma is limited to therange [0, 39] for a bit-depth of 8. In contrast, the QP for luma canvary in the range [0, 51] for a bit-depth of 8. The range is increasedappropriately for higher bit-depths for both luma and chroma. With thisdesign, the QP value used for chroma saturates at a much smaller valuecompared to the QP value used for luma. That is, the highest QP value(and highest QSS) used for chroma is much smaller than the highest QPvalue (and highest QSS) used for luma. This restriction can causeproblems for rate control in low bit-rate applications, when anexcessive (inefficient, unwarranted) amount of bits is allocated toencoding of chroma components relative to luma components. Also, thedesign may not be well-suited for a wide variety of color formats.

In particular, according to the HEVC design in JCTVC-I1003, the QPs usedfor chroma components Cb and Cr (that is, QPP_(Cb) and QP_(Cr)) arederived from the QP used for luma component (QP_(Y)) as follows. Thevalues of QP_(Cb) and QP_(Cr) are equal to the value of QP_(C) asspecified in Table 1 based on a lookup for the intermediate QP indexqP_(I). Table 1 specifies QP_(C) as a function of qP_(I).

TABLE 1 QPc as a function of qP_(I) in JCTVC-11003 qP_(I) QP_(C) qP_(I)QP_(C) <30 = qP_(I) 41 36 30 29 42 37 31 30 43 37 32 31 44 37 33 32 4538 34 32 46 38 35 33 47 38 36 34 48 39 37 34 49 39 38 35 50 39 39 35 5139 40 36

The intermediate QP index qP_(I) can be qP_(ICb) (for Cb chromacomponent) or qP_(ICr) (Cr chroma component). It is derived as:

qP_(ICb)=Clip3(−QpBdOffset_(C), 51, QP_(Y)+cb_qp_offset), or

qP_(ICr)=Clip3(−QpBdOffset_(C), 51, QP_(Y)+cr_qp_offset),

where Clip3 is a function defined as follows. Clip3 (x, y, z) is x whenz<x, is y when z>v, and is z otherwise. The values cb_qp_offset andcr_qp_offset are picture-level chroma QP offset values that can besignalled in a picture parameter set (“PPS”). QP_(Y) is a QP value forluma. QpBdOffset_(C) is a chroma QP range offset that depends on chromabit depth (increasing for higher bit depths). Example values forQpBdOffset_(C) are 0, 6, 12, 18, 24 and 36, whereQpBdOffset_(C)=6*bit_depth_chroma_minus8, and bit_depth_chroma_minus8 isin the range of 0 to 6, inclusive, for bit depths of 8 to 14 bits persample.

In the HEVC design in JCTVC-I1003, a further adjustment to QPs for lumaand chroma can occur based on bit depth. This type of adjustment is alsoan aspect of the innovations described below. That is, such adjustmentsfor bit depth can also be made for the innovations described below. Forthe purpose of clarity, the equations representing this adjustment inthe HEVC design in JCTVC-I1003 are:

QP′_(Y)=QP_(Y)+QpBdOffset_(Y),

QP′_(Cb)=QP_(Cb)+QpBdOffset_(C), and

QP′_(Cr)=QP_(Cr)+QpBdOffset_(C).

Thus, the overall process of deriving a chroma QP value (e.g., QP′_(Cb)or QP′_(Cr)) is to: (1) determine an intermediate QP index qP_(I) (e.g.,qP_(ICb) or qP_(ICr)) from the luma QP value (QP_(Y)) and picture-levelchroma QP offset (e.g., cb_qp_offset or cr_qp_offset), (2) determine avalue QP_(C), (e.g., QP_(Cr) or QP_(Cr)) through a table look-upoperation, and (3) adjust the value of QP_(C) by QpBdOffset_(C).

A. New Approaches to Expressing QP for Chroma

Various innovations described herein extend the QP range of chroma tomatch QP range of luma.

FIG. 7 shows a generalized technique (700) for determining chroma QPoffsets during encoding. A video encoder such as one described abovewith reference to FIG. 5 or other image or video encoder performs thetechnique (700).

The encoder encodes image or video content for which values of QP varyaccording to a relationship between a primary component and one or moresecondary components. As part of the encoding, the encoder determines(710) a QP index from a primary component QP and a secondary componentQP offset. For example, the primary component is a luma component, andthe one or more secondary components are one or more chroma components.Alternatively, the primary component and secondary component(s) areother types of color components (e.g., RGB).

A chroma QP offset can incorporate a picture-level chroma QP offset anda slice-level chroma QP offset. The encoder can determine the QP index(as variable qP_(I)) according to qP_(I)=Clip3(a, b,QP_(Y)+qp_offset+slice_qp_delta), where QP_(Y) represents luma QP,qp_offset represents the picture-level chroma QP offset, slice_qp_deltarepresents the slice-level chroma QP offset, and Clip3(a, b, c)represents a function that clips the value of c to the range of a to b.For example, in the function Clip3(−QpBdOffset_(C), 57,QP_(Y)+qp_offset+slice_qp_delta), the value ofQP_(Y)+qp_offset+slice_qp_delta is limited to the range of−QpBdOffset_(C) . . . 57, inclusive of the end values of the range.Alternatively, the encoder determines the QP index according to adifferent formula, for example, another formula in one of the newapproaches described below.

In some implementations, the encoder constrains the values of thepicture-level chroma QP offset, slice-level chroma QP offset and sum ofthe picture-level chroma QP offset and slice-level chroma QP offset to adefined range (e.g., −12 to 12). Alternatively, the values of chroma QPoffsets are constrained to another range (e.g., −6 to 6) or areunconstrained.

The encoder maps (720) the QP index to a secondary component QP. Therange of secondary component QP values is extended relative to certainprior approaches, such that an upper limit of the range of QSS indicatedby the secondary component QP substantially matches an upper limit ofthe range of QSS indicated by the primary component QP. The upper limitof the range of QSS indicated by the secondary component QP can exactlymatch the upper limit of the range of QSS indicated by the primarycomponent QP, Or, the upper limit of the range of QSS indicated by thesecondary component QP can differ from the upper limit of the range ofQSS indicated by the primary component QP by a factor of at most 2(e.g., when QSS relates to QP in a roughly logarithmic way such asapproximately QSS=S*2^((QP/6)) for a scaling factor S, the values of QSSare roughly S*2^(8.5) versus S*2^(7.5) for an upper limit of QSS forprimary component QP of 51 and upper limit of QSS for secondarycomponent QP of 45, or for an upper limit of QSS for secondary componentQP of 51 and upper limit of QSS for primary component QP of 45).

The mapping can follow a table that maps different values of QP index tocorresponding values of secondary component QP. For example, the tableis

qP_(I) QP_(C) qP_(I) QP_(C) <30 = qPr 37 34 30 29 38 35 31 30 39 35 3231 40 36 33 32 41 36 34 33 42 37 35 33 43 37 36 34 >43 = qP_(I) − 6where qP_(I) represents the QP index and QP_(C) represents a value ofchroma QP (or other secondary component QP).

Or, the mapping can use a function according to which a value of QPindex is mapped to a value of secondary component QP. For example,according to the function, a first range of values of QP index has alinear mapping to corresponding values of secondary component QP, asecond range of values of QP index has a non-linear mapping tocorresponding values of secondary component QP, and a third range ofvalues of QP index has a linear mapping to corresponding values ofsecondary component QP.

Or, the mapping can follow logic that maps different values of QP indexto corresponding values of secondary component QP. In some examples,such logic implements a piece-wise linear relationship between differentvalues of QP index and corresponding values of secondary component QP.For example, the logic is:

-   -   if (qP_(I)<30)        -   QP_(C)=qP_(I)    -   else if (qP_(I)>=30 && qP_(I)<=34)        -   QP_(C)=qP_(I)−1    -   else if (qP_(I)>34 && qP_(I)<44)        -   QP_(C)=33+((qP_(I)−34)>>1)    -   else        -   QP_(C)=qP_(I)−6.            where qP_(I) represents the QP index and QP_(C) represents a            value of chroma QP (or other secondary component QP) and            “>>1” represents an integer arithmetic right shift of one            bit position in two's complement arithmetic.

Example tables and mappings are described below.

With the primary component QP and secondary component QP, the encodercan perform operations such as quantization of transform coefficients.For example, the encoder can quantize transform coefficients for one ormore portions of a slice of a picture, then adjust the primary componentQP and/or secondary component QP for quantization of other slices orpictures.

The encoder outputs (730) at least part of a bitstream including theencoded content. The bitstream can include a flag (e.g., in a PPS orelsewhere) that indicates the presence or absence of slice-level chromaQP offsets in slice headers.

In some implementations, for a range of values of QP index associatedwith high QSS (i.e., coarse quantization), the relationship between theprimary component QP and secondary component QP is characterized by oneor more of the following features.

-   -   for a constant value of secondary component QP offset, the        secondary component QP is identical to the primary component QP;    -   values of QSS change at a ratio of QSS represented by the        primary component QP to QSS represented by the secondary        component QP, where the ratio is at most 2 for default value of        zero for the secondary component QP offset;    -   a change in value of the primary component QP causes a change of        the same size in value of the secondary component QP, such that        ratio of change in the primary component QP to change in the        secondary component QP is 1; and    -   for a value of the secondary component QP offset that is a        particular value (e.g., six), the secondary component QP is        identical to the primary component QP.

FIG. 8 shows a generalized technique (800) for determining chroma QPoffsets during decoding. A video decoder such as one described abovewith reference to FIG. 6 or other image or video decoder performs thetechnique (800).

The decoder receives (810) at least part of a bitstream includingencoded image or video content for which values of QP vary according toa relationship between a primary component and one or more secondarycomponents.

The decoder decodes at least some of the encoded content. As part of thedecoding, the decoder determines (820) a QP index from a primarycomponent QP and a secondary component QP offset. For example, theprimary component is a luma component, and the one or more secondarycomponents are one or more chroma components. Alternatively, the primarycomponent and secondary component(s) are other types of color components(e.g., RGB).

A chroma QP offset can incorporate a picture-level chroma QP offset anda slice-level chroma QP offset. The decoder can determine the QP index(as variable qP_(I)) according to qP_(I)=Clip3(a, b,QP_(Y)+qp_offset+slice_qp_delta), where QP_(Y) represents luma QP,qp_offset represents the picture-level chroma QP offset, slice_qp_deltarepresents the slice-level chroma QP offset, and Clip3(a, b, c)represents a function that clips the value of c to the range of a to b.For example, in the function Clip3(−QpBdOffset_(C), 57,QP_(Y)+qp_offset+slice_qp_delta), the value ofQP_(Y)+qp_offset+slice_qp_delta is limited to the range of−QpBdOffset_(C) . . . 57, inclusive of the end values of the range.Alternatively, the decoder determines the QP index according to adifferent formula, for example, another formula in one of the newapproaches described below.

The decoder maps (830) the QP index to a secondary component QP. Therange of secondary component QP values is extended relative to certainprior approaches, such that an upper limit of QSS indicated by the rangeof the secondary component QP substantially matches an upper limit ofthe range of QSS indicated by the primary component QP. The upper limitof the range of QSS indicated by the secondary component QP can exactlymatch the upper limit of the range of QSS indicated by the primarycomponent QP. Or, the upper limit of the range of QSS indicated by thesecondary component QP can differ from the upper limit of QSS indicatedby the range of the primary component QP by a factor of at most 2 (e.g.,when QSS relates to QP in a roughly logarithmic way such asapproximately QSS=S*2^((QP/6)) for a scaling factor S, the values of QSSare roughly S*2^(8.5) versus S*2^(7.5) for an upper limit of QSS forprimary component QP of 51 and upper limit of QSS for secondarycomponent QP of 45, or for an upper limit of QSS for secondary componentQP of 51 and upper limit of QSS for primary component QP of 45).

The mapping can follow a table that maps different values of QP index tocorresponding values of secondary component QP. For example, the tableis

qP_(I) QP_(C) qP_(I) QP_(C) <30 = qP_(I) 37 34 30 29 38 35 31 30 39 3532 31 40 36 33 32 41 36 34 33 42 37 35 33 43 37 36 34 43 = qP_(I) − 6where qP_(I) represents the QP index and QP_(C) represents a value ofchroma QP (or other secondary component QP).

Or, the mapping can use a function according to which a value of QPindex is mapped to a value of secondary component QP. For example,according to the function, a first range of values of QP index has alinear mapping to corresponding values of secondary component QP, asecond range of values of QP index has a non-linear mapping tocorresponding values of secondary component QP, and a third range ofvalues of QP index has a linear mapping to corresponding values ofsecondary component QP.

Or, the mapping can follow logic that maps different values of QP indexto corresponding values of secondary component QP. In some examples,such logic implements a piece-wise linear relationship between differentvalues of QP index and corresponding values of secondary component QP.For example, the logic is:

-   -   if (qP_(I)<30)        -   QP_(C)=qP_(I)    -   else if (qP_(I)>=30 && qP_(I)<=34)        -   QP_(C)=qP_(I)−1    -   else if (qP_(I)>34 && qP_(I)<44)        -   QP_(C)=33+((qP_(I)−34)>>1)    -   else        -   QP_(C)=qP_(I)−6.            where qP_(I) represents the QP index and QP_(C) represents a            value of chroma QP (or other secondary component QP).

Example tables and mappings are described below.

With the primary component QP and secondary component QP, the decodercan perform operations such as inverse quantization of transformcoefficients. For example, the decoder can inverse quantize transformcoefficients for one or more portions of a slice of a picture, thenadjust the primary component QP and/or secondary component QP forinverse quantization of other slices or pictures.

Some innovations described herein modify the process of deriving QP_(Cb)and QP_(Cr) from QP_(Y), compared to the HEVC design in JCTVC-I1003. Forthe following new approaches, the overall process of deriving a chromaQP value (e.g., QP′_(Cb) or QP′_(Cr)) is as follows. First, anintermediate QP index qP_(I) (e.g., qP_(ICb) or qP_(ICr)) is determinedfrom a luma QP value (QP_(Y)) and chroma QP offset. The chroma QP offsetaccounts for picture-level chroma QP offsets, and it may also accountfor slice-level chroma QP offset in some new approaches. Next, a valueQP_(C) (e.g., QP_(Cb) or QP_(Cr)) is determined through a table look-upoperation or other mapping operation. Then, the value of QP_(C) isadjusted by QpBdOffset_(C).

QP′_(Cb)=QP_(Cb)+QpBdOffset_(C), or

QP′_(Cr)=QP_(Cr)+QpBdOffset_(C).

The final stage can be skipped when QpBdOffset_(C) is zero. Again,example values for QpBdOffset_(C) are 0, 6, 12, 18, 24 and 36.

1. New Approach 1

In new approach 1, the values of QP_(Cb) and QP_(Cr) are equal to thevalue of QP_(C) as specified in Table 2, depending on the value of theindex qP_(I).

TABLE 2 QP_(C) as a function of qP_(I) in new approach 1 qP_(I) QP_(C)<30 =qP_(I) 30 29 31 30 32 31 33 32 34 32 35 33 36 34 37 34 38 35 39 3540 36 41 36 42 37 43 37 44 38 45 38 46 39 47 39 48 40 49 40 50 41 51 4152 42 53 42 54 43 55 43 56 44 57 44 58 45 59 45 60 46 61 46 62 47 63 4764 48 65 48 66 49 67 49 68 50 69 50 70 51 71 51

Compared to Table 1, Table 2 is extended from 51 to 71 for the indexqP_(I). Also, compared to Table 1, the chroma QP value QP_(C) isdifferent for values of index qP_(I) above 43. The index qP_(I) (forqP_(ICb) or qP_(ICr)) is derived as follows. In these equations theupper limit is 71 instead of 51.

qP_(ICb)=Clip3(−QpBdOffset_(C), 71, QP_(Y)+cb_qp_offset)

qP_(ICr)=Clip3(−QpBdOffset_(C), 71, QP_(Y)+cr_qp_offset)

The relationship between QP_(C) and qP_(I) can be specified as a tablefor every value of the index qP_(I). Alternatively, a table containingonly 5 entries is needed, and the remaining part can be implementedusing logic represented as follows:

-   -   if (qP_(I)<30)        -   QP_(C)=qP_(I)    -   else if (qP_(I)>=30 && qP_(I)<=34)        -   determine QP_(C) from table    -   else        -   QP_(C)=33+((qP_(I)−34)>>1)

2. New Approach 2

In new approach 2, the values of QP_(Cb) and QP_(Cr) are equal to thevalue of QP_(C) as specified in Table 3, depending on the value of theindex qP_(I).

TABLE 3 QPc as a function of qPi in new approach 2 qP_(I) QP_(C) qP_(I)QP_(C) <30 = qP_(I) 37 34 30 29 38 35 31 30 39 35 32 31 40 36 33 32 4136 34 32 42 37 35 33 43 37 36 34 >43 = qP_(I) − 6

Compared to Table 1, the chroma QP value QP_(C) is different for valuesof index qP_(I) above 43. The index qP_(I) (for qP_(ICb) or qP_(ICr)) isderived as follows. In these equations the upper limit is 57 instead of51, which effectively extends Table 3 up to qP_(I)=57.

qP_(ICb)=Clip3(−QpBdOffset_(c), 57, QP_(Y)+cb_qp_offset)

qP_(ICr)=Clip3(−QpBdOffset_(C), 57, QP_(Y)+cr_qp_offset)

The relationship between QP_(C) and qP_(I) can be specified as a tablefor every value of the index qP_(I). Alternatively, a table containingonly 5 entries is needed, and the remaining part can be implementedusing logic represented as follows:

-   -   if (qP_(I)<30)        -   QP_(C)=qP_(I)    -   else if (qP_(I)>=30 && qP_(I)<=34)        -   determine QP_(C) from table    -   else if (qP_(I)>34 && qP_(I)<44)        -   QP_(C)=33+((qP_(I)−34)>>1)    -   else        -   QP_(C)=qP_(I)−6

3. New Approach 3

In new approach 3, the values of QP_(Cb) and QP_(Cr) are equal to thevalue of QP_(C) as specified in Table 4, depending on the value of theindex qP_(I).

TABLE 4 QP_(C) as a function of qP_(I) in new approach 3 qP_(I) QP_(C)<30 =qP_(I) 30 29 31 30 32 31 33 32 34 33 35 33 36 34 37 34 38 35 39 3540 36 41 36 42 37 43 37 44 38 45 38 46 39 47 39 48 40 49 40 50 41 51 4152 42 53 42 54 43 55 43 56 44 57 44 58 45 59 45 60 46 61 46 62 47 63 4764 48 65 48 66 49 67 49 68 50 69 50 70 51 71 51

Compared to Table 1, Table 4 is extended from 51 to 71 for the indexqP_(I). Also, compared to Table 1, the chroma QP value QP_(C) isdifferent when the index qP_(I) is 34 and for values of index qP_(I)above 43. The index qP_(I) (for qP_(ICb) or qP_(ICr)) is derived asfollows. In these equations the upper limit is 71 instead of 51.

qP_(ICb)=Clip3(−QpBdOffset_(C), 71, QP_(Y)+cb_qp_offset)

qP_(ICR)=Clip3(−QpBdOffset_(C), 71, QP_(Y)+cr_qp_offset)

The relationship between QP_(C) and qP_(I) can be specified as a tablefor every value of the index qP_(I). Alternatively, the relationship canbe specified as a piece-wise linear function and be implemented usinglogic represented as follows:

-   -   if (qP_(I)<30)        -   QP_(C)=qP_(I)    -   else if (qP_(I)>=30 && qP_(I)<=34)        -   QP_(C)=qP_(I)−1    -   else        -   QP_(C)=33+((qP_(I)−34)>>1)

4. New Approach 4

In new approach 4, the values of QP_(Cb) and QP_(Cr) are equal to thevalue of QP_(C) as specified in Table 5, depending on the value of theindex qP_(I).

TABLE 5 QPc as a function of qPi in new approach 4 qP_(I) QP_(C) qP_(I)QP_(C) <30 = qP_(I) 37 34 30 29 38 35 31 30 39 35 32 31 40 36 33 32 4136 34 33 42 37 35 33 43 37 36 34 >43 = qP_(I) − 6

Compared to Table 1, the chroma QP value QP_(C) is different whenqP_(I)=34 and for values of index qP_(I) above 43. The index qP_(I) (forqP_(ICb) or qP_(ICr)) is derived as follows. In these equations theupper limit is 57 instead of 51, which effectively extends Table 5 up toqP_(I)=57.

qP_(ICb)=Clip3(−QpBdOffset_(C), 57, QP_(Y)+cb_qp_offset)

qP_(ICr)=Clip3(−QpBdOffset_(C), 57, QP_(Y)+cr_qp_offset)

The relationship between QP_(C) and qP_(I) can be specified as a tablefor every value of the index qP_(I). Alternatively, the relationship canbe specified as a piece-wise linear function and be implemented usinglogic represented as follows:

-   -   if (qP_(I)<30)        -   QP_(C)=qP_(I)    -   else if (qP_(I)>=30 && qP_(I)<=34)        -   QP_(c)=qP_(I)−1    -   else if (qP_(I)>34 && qP_(I)<44)        -   QP_(C)=33+((qP_(I)−34)>>1)    -   else        -   QP_(C)=qP_(I)−6

5. New Approach 5

New approach 5 combines new approach 3 with the use of slice-levelchroma QP offsets. The use of slice-level chroma QP offsets can beenabled/disabled using a flag signaled in the sequence parameter set(“SPS”), PPS or other higher level syntax structure. New approach 5 isotherwise identical to new approach 3 except that the values for theindex qP_(I) are derived as follows:

qP_(ICb)=Clip3(−QpBdOffset_(C), 71,QP_(Y)+cb_qp_offset+slice_qp_delta_cb)

qP_(ICr)=Clip3(−QpBdOffset_(C), 71,QP_(Y)+cr_qp_offset+slice_qp_delta_cr)

The variables slice_qp_delta_cb and slice_qp_delta_cr are slice-levelchroma QP offset values for Cb and Cr components, respectively, that canbe signalled in a slice header.

6. New Approach 6

Similarly, new approach 6 combines new approach 4 with the use ofslice-level chroma QP offsets. The use of slice-level chroma QP offsetscan be enabled/disabled using a flag signaled in the SPS, PPS or otherhigher level syntax structure. New approach 6 is otherwise identical tonew approach 4 except that the values for the index qP_(I) are derivedas follows:

qP_(ICb)=Clip3(−QpBdOffset_(C), 57,QP_(Y)+cb_qp_offset+slice_qp_delta_cb)

qP_(ICr)=Clip3(−QpBdOffset_(C), 57,QP_(Y)+cr_qp_offset+slice_qp_delta_cr)

7. Advantages of New Approaches

For each new approach in this section, the table for determining QP_(C)as a function of qP_(I) is effectively extended to enable reachinghigher values of chroma QP (indicating higher values of QSS for chroma,according to example relationships between QP and QSS). In particular,the tables are effectively extended such that the maximum possible valueof QP for chroma is now 51 instead of 39 (in JCTVC-I1003), This allowsfor more aggressive (i.e., coarse) quantization for chroma components inhigh QP scenarios, which reduces bitrate for the chroma components. Thesaved bits can instead be used for luma components, so as to improve theoverall quality. Also, for each new approach, the table can beimplemented using simple formulas/logic as described above.

New approaches 2, 4 and 6 have the following additional advantages.

First, the difference between quantization step sizes represented by QPvalue for luma and the corresponding QP value for chroma is preventedfrom becoming too extreme, especially for QP values at the high end ofthe extended table. Typically, a quantization step size (“QSS”) dependson QP value according to defined relation (e.g., roughly logarithmicrelation; in some implementations, approximately QSS=2^((QP/6)), suchthat QSS is directly proportional to QP in the exponent of therelation). When default values are used for chroma QP offsets (that is,offsets are set to 0), the ratio of QSS represented by QP index (derivedfrom QP for luma) to QSS for chroma can be as large as 4 in the HEVCdesign in JCTVC-I1003 (e.g., roughly 2^(8.5) versus 2^(6.5) for luma QPof 51 and chroma QP of 39), In new approaches 2, 4 and 6, in contrast,the ratio is at most 2 (e.g., roughly 2^(8.5) versus 2^(7.5) for luma QPof 51 and chroma QP of 45). Limiting the ratio for QSS can help preventexcessive bit usage for chroma components when quantization is intendedto be coarse.

Second, for the ratio of change in QP for luma to change in QP forchroma, a slope of 1 is enabled at high QP (high QSS) operation. Forhigh QP conditions (when qP_(I) is >43), a change of +1 for luma QPresults in a change of +1 for chroma QP, or a change of −1 for luma QPresults in a change of −1 for chroma QP. This helps an encodingcontroller maintain the balance between luma and chroma when changing QPvalues (e.g., during rate control to adjust overall quality versusbitrate). For this range of QP values, the ratio between luma and chromaquantization step sizes remains constant, which facilitates fine-grainedcontrol of bitrate without unexpected changes to the balance betweenluma and chroma.

Third, in some implementations (for which QP_(C) is qP_(I)−6 at high QPoperation), a fixed chroma QP offset of 6 can be used to achieve equalQSSs for luma and chroma at high QP (high QSS) operation. In some cases,an encoder may desire to code all planes using the same QSS (which ismade possible when QP_(Y)=QP_(C)). In the design in JCTVC-I1003, thismeans that the chroma QP offset may need to be adjusted depending on theQP, since the relationship between QP_(Y) and QP_(C) has a variabledifference (see Table 1). In contrast, in new approaches 2, 4 and 6, forvalues of qP_(I) greater than 43, QP_(C)=qP_(I)−6. So the differencebetween qP_(I) and QP_(C) is held at 6 for this range, and a fixedchroma QP offset of 6 can achieve the goal (QP_(Y)=QP_(C)).

Fourth, the chroma QP offset needed to achieve a desired relativerelationship (between the QSS for luma and chroma) is much smaller thanin JCTVC-I1003. For example, in JCTVC-I1003, if the encoder wants to usea QP of 39 for both luma and chroma, the necessary chroma QP offset is12. This value for offset becomes even larger if Table 1 is simplyextended at the same slope seen at the end. In new approaches 2, 4 and6, however, the same relative relationship can be achieved using a muchsmaller offset of 6.

Fifth, the extended range for chroma QP values does not significantlyimpact rate-distortion performance for common usage conditions with lowand mid-range QP values (for fine quantization and mid-rangequantization), since the modifications in the new approaches mostlyapply outside the range of QP values used in the common usageconditions. At the same time, however, for high QP (high QSS)situations, there are benefits in terms of rate-distortion performanceand encoder flexibility to using extended range for chroma QP. Fortypical high QP situations, the loss in chroma quality (from coarserquantization, saved bits, etc. using extended range chroma. QP) is morethan offset by gain in luma quality.

Any of the new approaches for expressing QP for chroma as a function ofQP for luma can be used in conjunction with a quantization scalingmatrix for establishing frequency-specific scaling factors forcoefficients of a luma component and/or chroma. component.

B. Constraints on Values of Chrorna QP Offsets

Constraints on the values of chroma QP offsets are useful in exampleimplementations such as those of new approaches 1-6 in order to limithuge quality differences between luma and chroma. In particular, therange of −12 to 12 is effective in example implementations for chroma QPoffset. (In the H.264/AVC standard, a chroma QP offset is similarlylimited to the range −12 to 12, inclusive.) This range has usefulproperties. For example, for new approach 4 at high QPs, since a chromaQP offset of 6 represents the case where luma QP is equal to the chromaQP, the offset of 12 represents the counter-point to an offset of 0. Atboth these chroma QP offsets (i.e., offsets of 0 and 12), the larger QSSis exactly 2× the smaller QSS (e.g., QSS of 2^(9.5) for chroma QP of 57is 2× the QSS of 2^(8.5) for chroma QP of 51, which is 2× the QSS of2^(7.5) for chroma QP of 45), for example relationships between QP andQSS.

In the case of new approaches 1 to 4, the constraints on values ofchroma QP offsets can be imposed on cb_qp_offset and cr_qp_offset. Fornew approaches 5 and 6, the constraints on values of chroma QP offsetscan be imposed on the values (cb_qp_offset+slice_qp_delta_cb) and(cr_qp_offset+slice_qp_delta_cr). Alternatively, for new approaches 5and 6, the constraints on values of chroma QP offsets can be imposed onindividual values for cb_qp_offset, slice_qp_delta_cb, cr_qp_offset andslice_qp_delta_cr.

C. Syntax and Semantics of Values for Slice-level Chroma QP Offsets

In new approaches 5 and 6, bitstream syntax and semantics support thesignalling of slice-level chroma QP offsets. Slice-level chroma QPoffsets provide the encoder with greater ability to precisely controlthe chroma QP for different regions within a picture. FIG. 9 a shows anew flag slicelevel_chroma_qp_flag in PPS RBSP syntax, and FIG. 9 bshows new values slice_qp_delta_cb and slice_qp_delta_cr in slice headersyntax, for example implementations. The entropy-coded valuesslice_qp_delta_cb and slice_qp_delta_cr are conditionally present in aslice header depending on the value of slicelevel_chroma_qp_flag in theapplicable PPS. Thus, when slice-level chroma QP offsets are not used,slice-level syntax overhead is avoided.

In the PPS syntax fragment (901) shown in FIG. 9 a , the valuescb_qp_offset and cr_qp_offset specify a base offset used in obtainingQP_(Cb) and QP_(Cr), respectively, as specified above. The valueslicelevel_chroma_qp_flag equal to 1 specifies that syntax elementsslice_qp_delta_cb and slice_qp_delta_cr are present in the associatedslice headers. Otherwise, the syntax elements slice_qp_delta_cb andslice_qp_delta_cr are not present in the associated slice headers.

In a slice header (as shown in the syntax fragment (902) in FIG. 9 b ),slice_qp_delta specifies the initial value of QP_(Y) to be used for allthe coding blocks in the slice until modified by the value ofcu_qp_delta in the coding unit layer. The initial QP_(Y) quantizationparameter for the slice is computed as

SliceQP_(Y)=26+pic_init_qp_minus26+slice_qp_delta

The value of slice_qp_delta is limited such that SliceQP_(Y) is in therange of −QpBdOffset_(Y) to +51, inclusive.

The values slice_qp_delta_cb and slice_qp_delta_cr specify a deltaoffset used in obtaining QP_(Cb) and QP_(Cr) respectively, as specifiedfor new approaches 5 and 6. When not present, the value of these syntaxelements is inferred to be 0.

D. Modified Deblock Filtering for Chroma

In the HEAT design in JCTVC-I1003, the filter “strength” (t_(C)parameter) used while deblocking a block edge of a chroma component isdetermined using a value QP_(C). The variable QP_(C) is determined asspecified in Table 1 using an index qP_(I) that is derived as:

qP_(I)=((QP_(Q)+QP_(P)+1)>>1),

where QP_(Q) and QP_(P) represent the luma QP values for the blockspresent on either side of the edge. The general idea is to adjust thefilter strength based on the QP values used to quantize the samplesaround the edge. This approach to determining qP_(I) for chroma deblockfiltering is inefficient when chroma QP offsets (cb_qp_offset andcr_qp_offset) are not equal to zero. For different, non-zero values ofchroma QP offsets, the QP used for chroma components would be different,but the filter strength remains the same.

In some example implementations, the effect of chroma QP offsets istaken into account when determining qP_(I) for chroma deblock filtering.In these implementations, index qP_(I) is derived as:

qP_(I)=Clip3(0, 51, ((QP_(Q)+QP_(P)−1)>>1+cqp_offset)),

where cqp_offset represents cb_qp_offset and crqp_offset for componentsCb and Cr respectively. In these example implementations, the derivationof the index qP_(I) for chroma deblock filtering accounts for theeffects of chroma QP offsets, but otherwise is based upon the way qP_(I)is derived in JCTVC-I1003 when expressing QP for chroma as a function ofQP for luma.

In other example implementations, when one of the new approachesdescribed above for ways of expressing QP for chroma as a function of QPfor luma is adopted, the index qP_(I) for deblock filtering can bederived as:

qP_(I)=Clip3(0, QP_(max), (((QP_(Q)+QP_(P)+1)>>1)+cqp_offset)),

where QP_(max), and cqp_offset are dependent on the new approach used.For new approaches 1, 3 and 5, for example, QP_(max), is equal to 71.For new approaches 2, 4 and 6, for example, QP_(max) is equal to 57. Fornew approaches 1 to 4, cqp_offset represents cb_qp_offset andcr_qp_offset for components Cb and Cr respectively. For new approaches 5and 6, cqp_offset represents (cb_qp_offset+slice_qp_delta_cb) and(cr_qp_offset+slice_qp_delta_cr) for components Cb and Cr respectively.More generally, when the value of the index qP_(I) is derived fordeblock filtering, (QP_(Q)+QP_(P)+1)>>1 replaces QP_(Y), and a. chromaQP offset is considered.

The way that the variable qP_(I) is used in deblock filtering depends onimplementation. For example, the variable qP_(I) is then used todetermine a variable QP_(C) as specified in table 5, above. Anothervariable Q is derived as:

Q=Clip3(0, 53, QP_(C)+2*(bS−1)+(slice_tc_offset_div2<<1)),

where bS is a boundary filtering strength set depending on coding mode(intra or inter), presence of non-zero transform coefficients in ablock, motion vector values and/or other factors, whereslice_tc_offsetdiv2 is the value of the syntax elementslice_tc_offset_div2 for the slice that contains a first sample on theside of an edge to be filtered. The value of the variable t_(C)′ is thendetermined based on the mapping of Q to t_(C)′ shown in the followingtable.

TABLE 6 t_(C)′ as a function of Q Q t_(C)′ 0 0 1 0 2 0 3 0 4 0 5 0 6 0 70 8 0 9 0 10 0 11 0 12 0 13 0 14 0 15 0 16 0 17 0 18 1 19 1 20 1 21 1 221 23 1 24 1 25 1 26 1 27 2 28 2 29 2 30 2 31 3 32 3 33 3 34 3 35 4 36 437 4 38 5 39 5 40 6 41 6 42 7 43 8 44 9 45 10 46 11 47 13 48 14 49 16 5018 51 20 52 22 53 24Finally, the control parameter t_(C) is derived as:t_(C)=t_(C)′*(1<<BitDepthC−8)).

E. Alternatives

For the sake of illustration, the detailed description includes variousexamples with specific names for some parameters and variables. Theinnovations described herein are not limited to implementations withparameters or variables having such names. Instead, the innovationsdescribed herein can be implemented with various types of parameters andvariables.

For instance, some of the examples described herein include theparameters slicelevel_chroma_qp_flag, cb_qp_offset, cr_qp_offset,slice_qp_delta_cb and slice_qp_delta_cr. In the version of the HEVCstandard in JCTVC-K1003, slicelevel_chroma_qp_flag is relabeledpic_slice_chroma_qp_offsets_present_flag but has essentially the samemeaning. The picture-level chroma QP offsets are called pic_cb_qp_offsetand pic_cr_qp_offset, instead of cb_qp_offset and cr_qp_offset.Slice-level chroma QP offsets are called slice_cb_qp_offset andslice_cr_qp_offset, as opposed to slice_qp_delta_cb andslice_qp_delta_cr. The examples described herein also apply for theparameters as relabeled.

In some examples described herein, a QP value is signaled in thebitstream as QP minus 26, and the QSS is S*2^((QP/6)) or roughlyS*2^((QP/6)), where S is a scaling factor. In this relationship, a highvalue of QP signifies a high (i.e., coarse) QSS, and a low value of QPindicates a low (i.e., fine) QSS. Alternatively, QP can be inverselyrelated to QSS. For example, a QP value is signaled in the bitstream as25 minus QP, and the QSS is S*2^(((51−QP)/6)) or approximatelyS*2^(((51−QP)/6)). In this example, the same QSS values can effectivelybe signaled, but a high value of QP signifies a low QSS, and a low valueof QP signifies a high QSS. More generally, the innovations describedherein can be applied for various relationships between QP and QSS,including the relationships described above as well as relationships inwhich the QP is a parameter such as the parameter called QUANT in theH.263 standard, and relationships in which the QP is a parameter such asthe parameter called quantiser_scale in the H.262 standard.

In view of the many possible embodiments to which the principles of thedisclosed invention may be applied, it should be recognized that theillustrated embodiments are only preferred examples of the invention andshould not be taken as limiting the scope of the invention. Rather, thescope of the invention is defined by the following claims. We thereforeclaim as our invention all that comes within the scope and spirit ofthese claims.

1.-30. (canceled)
 31. In a computer system that implements a videodecoder, a method comprising: receiving encoded data in a bitstream forwhich values of quantization parameter (QP) vary according to arelationship between a luma component and chroma components, wherein theencoded data in the bitstream includes: a flag in a picture parameterset that indicates presence of slice-level chroma QP offsets in sliceheaders; syntax elements that indicate picture-level chroma QP offsets;and syntax elements that indicate the slice-level chroma QP offsets; anddecoding at least some of the encoded data to reconstruct one or morepictures, including, for a portion of a given picture among the one ormore pictures: determining a QP index from a luma component QP and achroma component QP offset, wherein the chroma component QP offsetincorporates one of the picture-level chroma QP offsets and one of theslice-level chroma QP offsets, the QP index being determined accordingto:qP_(I)=Clip3(a, b, QP_(Y)+qp_offset+slice_qp_delta), where qP_(I)represents the QP index, QP_(Y) represents the luma component QP,qp_offset represents the one of the picture-level chroma QP offsets,slice_qp_delta represents the one of the slice-level chroma QP offsets,and Clip3(a, b, c) represents a function that clips the value of c tothe range of a to b; and mapping the QP index to a chroma component QP.32. The method of claim 31, wherein the mapping follows a table thatmaps different values of QP index to corresponding values of chromacomponent QP.
 33. The method of claim 31, wherein the mapping followslogic that maps different values of QP index to corresponding values ofchroma component QP.
 34. The method of claim 31, wherein the decodingfurther includes: inverse quantizing transform coefficients based atleast in part on the chroma component QP.
 35. The method of claim 31,wherein the encoded data in the bitstream further includes syntaxelements that at least in part indicate the luma component QP.
 36. Themethod of claim 35, wherein the syntax elements that at least in partindicate the luma component QP include a picture-level luma QP value, aslice-level QP offset value, and a unit-level QP offset value.
 37. Themethod of claim 31, wherein the syntax elements that indicate thepicture-level chroma QP offsets indicate a picture-level Cb QP offsetvalue and a picture-level Cr QP offset value.
 38. The method of claim31, wherein the syntax elements that indicate the slice-level chroma QPoffsets indicate a slice-level Cb QP offset value and a slice-level CrQP offset value.
 39. One or more non-transitory computer-readable mediahaving stored therein computer-executable instructions for causing oneor more processing units, when programmed thereby, to perform operationscomprising: encoding one or more pictures, thereby producing encodeddata, including, as part of a motion compensation loop, for a portion ofa given picture among the one or more pictures: determining aquantization parameter (QP) index indicated by a luma component QP and achroma component QP offset, wherein the chroma component QP offsetincorporates one of multiple picture-level chroma QP offsets and one ofmultiple slice-level chroma QP offsets, the QP index being determined ina manner consistent with:qP_(I)=Clip3(a, b, QP_(Y)+qp_offset+slice_qp_delta), where qP_(I)represents the QP index, QP_(Y) represents the luma component QP,qp_offset represents the one of the multiple picture-level chroma QPoffsets, slice_qp_delta represents the one of the multiple slice-levelchroma QP offsets, and Clip3(a, b, c) represents a function that clipsthe value of c to the range of a to b; and mapping the QP index to achroma component QP; and outputting the encoded data in a bitstream forwhich values of QP vary according to a relationship between a lumacomponent and chroma components, wherein the encoded data in thebitstream includes: a flag in a picture parameter set that indicatespresence of the multiple slice-level chroma QP offsets in slice headers;syntax elements that indicate the multiple picture-level chroma QPoffsets; and syntax elements that indicate the multiple slice-levelchroma QP offsets.
 40. The one or more computer-readable media of claim39, wherein the encoding further includes, as part of the motioncompensation loop, for the portion of the given picture: inversequantizing transform coefficients based at least in part on the chromacomponent QP.
 41. The one or more computer-readable media of claim 39,wherein the encoded data in the bitstream further includes syntaxelements that at least in part indicate the luma component QP.
 42. Theone or more computer-readable media of claim 41, wherein the syntaxelements that at least in part indicate the luma component QP include apicture-level luma QP value, a slice-level QP offset value, and aunit-level QP offset value.
 43. The one or more computer-readable mediaof claim 39, wherein the syntax elements that indicate the picture-levelchroma QP offsets indicate a picture-level Cb QP offset value and apicture-level Cr QP offset value.
 44. The one or more computer-readablemedia of claim 39, wherein the syntax elements that indicate theslice-level chroma QP offsets indicate a slice-level Cb QP offset valueand a slice-level Cr QP offset value.
 45. One or more computer-readablememory or storage devices having stored thereon encoded data in abitstream for which values of quantization parameter (QP) vary accordingto a relationship between a luma component and chroma components,wherein the encoded data in the bitstream includes: a flag in a pictureparameter set that indicates presence of slice-level chroma QP offsetsin slice headers, syntax elements that indicate picture-level chroma QPoffsets, and syntax elements that indicate the slice-level chroma QPoffsets, and wherein the encoded data is organized to facilitatedecoding, with a computer system that implements a video decoder, of atleast some of the encoded data to reconstruct one or more pictures byoperations that include, for a coding unit of a given picture among theone or more pictures: determining a QP index from a luma component QPand a chroma component QP offset, wherein the chroma component QP offsetincorporates one of the picture-level chroma QP offsets and one of theslice-level chroma QP offsets, the QP index being determined accordingto:qP_(I)=Clip3(a, b, QP_(Y)+qp_offset+slice_qp_delta), where qP_(I)represents the QP index, QP_(Y) represents the luma component QP,qp_offset represents the one of the picture-level chroma QP offsets,slice_qp_delta represents the one of the slice-level chroma QP offsets,and Clip3(a, b, c) represents a function that clips the value of c tothe range of a to b; and mapping the QP index to a chroma component QP.46. The one or more computer-readable memory or storage devices of claim45, wherein the operations further include, for the coding unit of thegiven picture: inverse quantizing transform coefficients based at leastin part on the chroma component QP.
 47. The one or morecomputer-readable memory or storage devices of claim 45, wherein theencoded data in the bitstream further includes syntax elements that atleast in part indicate the luma component QP.
 48. The one or morecomputer-readable memory or storage devices of claim 47, wherein thesyntax elements that at least in part indicate the luma component QPinclude a picture-level luma QP value, a slice-level QP offset value,and a unit-level QP offset value.
 49. The one or more computer-readablememory or storage devices of claim 45, wherein the syntax elements thatindicate the picture-level chroma QP offsets indicate a picture-level CbQP offset value and a picture-level Cr QP offset value.
 50. The one ormore computer-readable memory or storage devices of claim 45, whereinthe syntax elements that indicate the slice-level chroma QP offsetsindicate a slice-level Cb QP offset value and a slice-level Cr QP offsetvalue.